home *** CD-ROM | disk | FTP | other *** search
-
-
- K N O W N B U G S I N S E N D M A I L
- (for 8.7)
-
-
- The following are bugs or deficiencies in sendmail that I am aware of
- but which have not been fixed in the current release. You probably
- want to get the most up to date version of this from FTP.CS.Berkeley.EDU
- in /ucb/sendmail/KNOWNBUGS. For descriptions of bugs that have been
- fixed, see the file RELEASE_NOTES (in the root directory of the sendmail
- distribution).
-
- This list is not guaranteed to be complete.
-
-
- * Null bytes are not handled properly in headers.
-
- Sendmail should handle full binary data. As it stands, it handles
- all values in the body, but only 0x01-0x80 and 0xA0-0xFF in
- the header. Notably missing is 0x00, which would require a major
- restructuring of the code -- for example, almost no C library support
- could be used to handle strings.
-
- * Duplicate error messages.
-
- Sometimes identical, duplicate error messages can be generated. As
- near as I can tell, this is rare and relatively innocuous.
-
- * $c (hop count) macro improperly set.
-
- The $c macro is supposed to contain the current hop count, for use
- when calling a mailer. This macro is initialized too early, and
- is always zero (or the value of the -c command line flag, if any).
- This macro will probably be removed entirely in a future release;
- I don't believe there are any mailers left that require it.
-
- * If you EXPN a list or user that has a program mailer, the output of
- EXPN will include ``@local.host.name''. You can't actually mail to
- this address. It's not clear what the right behaviour is in this
- circumstance.
-
- * MX records that point at non-existent hosts work strangly.
-
- Consider the DNS records:
-
- hostH MX 1 hostA
- MX 2 hostB
- hostA A 128.32.8.9
-
- (note that there is no A record for hostB). If hostA is down,
- an attempt to send to hostH gives "host unknown" -- that is, it
- reflects out the status on the last host it tries, which in this
- case is hostB, which is unknown. It probably ought to eliminate
- hostB early in processing.
-
- * \231 considered harmful.
-
- Header addresses that have the \231 character (and possibly others
- in the range \201 - \237) behave in odd and usually unexpected ways.
-
- * accept() problem on SVR4.
-
- Apparently, the sendmail daemon loop (doing accept()s on the network)
- can get into a wierd state on SVR4; it starts logging ``SYSERR:
- getrequests: accept: Protocol Error''. The workaround is to kill
- and restart the sendmail daemon. We don't have an SVR4 system at
- Berkeley that carries more than token mail load, so I can't validate
- this. It is likely to be a glitch in the sockets emulation, since
- "Protocol Error" is not possible error code with Berkeley TCP/IP.
-
- I've also had someone report the message ``sendmail: accept:
- SIOCGPGRP failed errno 22'' on an SVR4 system. This message is
- not in the sendmail source code, so I assume it is also a bug
- in the sockets emulation. (Errno 22 is EINVAL "Invalid Argument"
- on all the systems I have available, including Solaris 2.x.)
-
- * Sending user deletion not done properly in :include: lists.
-
- If you don't have the "m" (me too) option set, then a person
- sending to a list that contains themselves should not get a copy
- of the message. However, if that list points to a :include: file
- that has one address per line, this will break, and the sender
- will always get a copy of their own message, just as though the
- "m" option were set.
-
- You can eliminate this by adding commas at the end of each line
- of the :include: file.
-
- * Excessive mailing list nesting can run out of file descriptors.
-
- If you have a mailing list that includes lots of other mailing
- lists, each of which has a separate owner, you can run out of
- file descriptors. Each mailing list with a separate owner uses
- one open file descriptor (prior to 8.6.6 it was three open
- file descriptors per list). This is particularly egregious if
- you have your connection cache set to be large.
-
- * Connection caching breaks if you pass the port number as an argument.
-
- If you have a definition such as:
-
- Mport, P=[IPC], F=kmDFMuX, S=11/31, R=21,
- M=2100000, T=DNS/RFC822/SMTP,
- A=IPC [127.0.0.1] $h
-
- (i.e., where $h is the port number instead of the host name) the
- connection caching code will break because it won't notice that
- two messages addressed to different ports should use different
- connections.
-
- * ESMTP SIZE underestimates the size of a message
-
- Sendmail makes no allowance for headers that it adds, nor does it
- account for the SMTP on-the-wire \r\n expansion. It probably doesn't
- allow for 8->7 bit MIME conversions either.
-
-
- (Version 8.21, last updated 8/27/95)
-